home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-bgp-bgp4ospf-interact-01.txt
< prev
next >
Wrap
Text File
|
1993-03-21
|
49KB
|
1,234 lines
Network Working Group K. Varadhan
Request for Comments: DRAFT OARnet
S. Hares
NSFnet/Merit
Y. Rekhter
IBM
March 15, 1993
BGP4/IDRP for IP---OSPF Interaction
Table of Contents
1. Introduction .................................................... 2
2. Reachability Information Exchange ............................... 4
2.1. Exporting OSPF information into BGP/IDRP ..................... 4
2.2. Importing BGP/IDRP information into OSPF ...................... 6
3. BGP/IDRP Identifier and OSPF router ID .......................... 7
4. Setting OSPF tags, ORIGIN and PATH attributes ................... 8
4.1. Semantics of the characteristics bits ......................... 10
4.2. Configuration parameters for setting the OSPF tag ............. 12
4.3. Manually configured tags ...................................... 12
4.4. Automatically generated tags .................................. 13
4.4.1. Destinations with incomplete path information, PathLength =0 . 13
4.4.2. Destinations with incomplete path information, PathLength =1 . 13
4.4.3. Destinations with incomplete path information, PathLength >=1 14
4.4.4. Destinations with complete path information, PathLength =0 ... 14
4.4.5. Destinations with complete path information, PathLength =1 ... 15
4.4.6. Destinations with complete path information, PathLength >=1 .. 16
4.5. Miscellaneous tag settings .................................... 16
4.6. Summary of the TagType field setting .......................... 17
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 17
6. Changes from the BGP 3 - OSPF interactions document ............. 18
7. Security Considerations ......................................... 19
8. Acknowledgements ................................................ 19
9. Bibliography .................................................... 20
10. Appendix ....................................................... 21
11. Author's Address ............................................... 22
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
Varadhan [Page 1]
INTERNET DRAFT (Expires September 15, 1993) March 93
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or
IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
1. Introduction
This document defines the various criteria to be used when designing
an Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4]
or IDRP for IP[IDRP] with other ASBRs external to the AS, and
OSPF[RFC1247] as its IGP.
All future references of BGP in this document will refer to BGP
version 4, as defined in [BGP-4]. All reference to IDRP are
references to the Inter-Domain Routing Protocol (ISO 10747) which has
been defined by the IDRP for IP document [IDRP] for use in Autonomous
Systems.
This document defines how the following fields in OSPF and attributes
in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
at an ASBR:
IDRP came out of the same work as BGP, and may be consider a follow
on to BGP-3 and BGP-4. Most fields defined in the interaction
between BGP and IDRP are named the same. Where different, the IDRP
fields are shown separately.
BGP/IDRP MULTI_EXIT_DISC vs. OSPF cost and type
BGP ORIGIN and AS_PATH vs. OSPF tag
IDRP EXT_INFO and RD_PATH
BGP/IDRP NEXT_HOP vs. OSPF Forwarding Address
BGP/IDRP LOCAL_PREF vs. OSPF cost
IDRP contains an RD_PATH field which serves the same purpose as an
AS_PATH field for IDRP for IP. In this document, we will use the
term PATH to refer to the BGP AS_PATH, or the IDRP RD_PATH depending
Varadhan [Page 2]
INTERNET DRAFT (Expires September 15, 1993) March 93
on the context of the protocol being used.
Both IDRP and BGP provide a mechanism to indicate whether the routing
information was originated via IGP, or some other means. In IDRP, if
a route information is originated by means other than an IGP, then
the EXT_INFO attribute is present. Likewise, in BGP, if a route
information is originated by means other than an IGP, then the ORIGIN
attribute is set to <EGP> or <INCOMPLETE>. For the rest of the
document, we will distinguish between the two cases:
(a) Route information was originated via IGP
(b) Route information was originated by some other means.
The former case is realized in IDRP by not including the EXT_INFO
attribute, and in BGP by setting the BGP ORIGIN=<IGP>; The latter
case is realized by including the EXT_INFO attribute in IDRP, and by
setting the BGP ORIGIN=<EGP>. For the rest of the document, we will
use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
ORIGIN=<EGP> to refer to the latter.
One other difference between IDRP and BGP remains. IDRP for IP iden-
tifies an autonomous system by an identifier of variable length that
is syntactically identical to an NSAP address prefix, and explicitly
embeds the autonomous system number[IDRP-IP]. BGP identifies an
autonomous system just by an autonomous system number. Since there
is a one-to-one mapping between how an autonomous system is identi-
fied in IDRP and in BGP, for the rest of the document, we shall iden-
tify an autonomous system by its autonomous system number.
For a more general treatise on routing and route exchange problems,
please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
This document uses the two terms ``Autonomous System'' and ``Routing
Domain.'' The definitions for the two are below:
The term Autonomous System is the same as is used in the BGP
RFC[RFC1267], given below:
``The use of the term Autonomous System here stresses the fact
that, even when multiple IGPs and metrics are used, the
administration of an AS appears to other ASs to have a single
coherent interior routing plan and presents a consistent picture of
what destinations are reachable through it. From the standpoint of
exterior routing, an AS can be viewed as monolithic: reachability
to destinations directly connected to the AS must be equivalent
from all border gateways of the AS.''
Varadhan [Page 3]
INTERNET DRAFT (Expires September 15, 1993) March 93
The term Routing Domain was first used in [ROUTE-LEAKING] and is
given below:
``A Routing Domain is a collection of routers which coordinate
their routing knowledge using a single [instance of a] routing
protocol.''
By definition, a Routing Domain forms a single Autonomous System,
but an Autonomous System may be composed of a collection of Routing
Domains.
BGP, IDRP and OSPF have the concept of a set of reachable
destinations. This set is called NLRI or Network Layer
Reachability Information. The set can be represented either as an
IP address prefix, or an address, mask pair. Note that if the mask
is contiguous in the latter, then the two representations are
equivalent. In this document, we use the term `address/mask pair''
in the context of OSPF, and ``destination'' or ``set of reachable
destinations'' in the context of BGP or IDRP.
This document follows the conventions embodied in the Host
Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
"SHOULD," and "MAY" for the various requirements.
A minimal implementation of BGP/IDRP OSPF exchange SHOULD not
import BGP/IDRP routes into the OSPF RD (section 2.1, bullet 1),
MUST set the BGP/IDRP identifier to be the same as OSPF router ID
(section 3), MUST set the OSPF tag accurately (section 4). It is
strongly recommended that implementors implement more than a
minimalistic specification.
2. Reachability Information Exchange
This section discusses the constraints that must be met to exchange
the set of reachable destinations between an external BGP/IDRP peer
from another AS and internal OSPF address/mask pairs.
2.1. Exporting OSPF information into BGP
1. The administrator MUST be able to selectively export
address/mask pairs into BGP/IDRP via an appropriate filter
mechanism.
This filter mechanism MUST support such control with the
granularity of an address/mask pair.
This filter mechanism will be the primary method of
Varadhan [Page 4]
INTERNET DRAFT (Expires September 15, 1993) March 93
aggregation of OSPF internal and type 1 and type 2 external
routes within the AS into BGP/IDRP.
Additionally, the administrator MUST be able to filter based
on the OSPF tag and the various sub-fields of the OSPF tag.
The settings of the tag and the sub-fields are defined in
section 4 in more detail.
o The default MUST be to export no routes from OSPF into
BGP/IDRP. A single configuration parameter MUST permit
all OSPF inter-area and intra-area address/mask pairs to
be exported into BGP/IDRP.
OSPF external address/mask pairs of type 1 and type 2
MUST never be exported into BGP/IDRP unless they are
explicitly configured.
2. An address/mask pair having a non-contiguous mask MUST not be
exported to BGP/IDRP.
3. When configured to export an address/mask pair from OSPF into
BGP/IDRP, the ASBR MAY advertise the route containing the set
of reachable destinations via BGP/IDRP as soon as at least
one of the destinations in the address/mask pair is
determined to be reachable via OSPF; it MUST stop advertising
the route containing the set of reachable destinations when
none of the destinations in the address/mask pair is
reachable via OSPF.
4. The network administrator MUST be able to statically
configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
be used for any route.
o The default MUST be to omit the MULTI_EXIT_DISC in the
route advertised via BGP/IDRP.
5. An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
mechanism to set up a minimum amount of time that must elapse
between the learning of a new address/mask pair via OSPF and
subsequent advertisement of the address/mask pair via
BGP/IDRP to the external neighbours.
o The default value for this setting MUST be 0, indicating
that the address/mask pair is to be advertised to the
neighbour BGP/IDRP peers instantly.
Note that BGP and IDRP mandate a mechanism to dampen the
inbound advertisements from adjacent neighbours. See
Varadhan [Page 5]
INTERNET DRAFT (Expires September 15, 1993) March 93
the variable MinRouteAdvertisementInterval in section
9.2.3.1, [BGP-4] or in section 7.17.3.1, [DIS ballot
IDRP].
2.2. Importing BGP/IDRP information into OSPF
1. A BGP/IDRP speaker can advertise an externally received route
into OSPF if this is route is selected at the completion of
the phase 2 route selection process, which includes the tie
break mechanism.
2. BGP/IDRP implementations SHOULD allow an AS to control
announcements of BGP/IDRP learned set of reachable
destinations into OSPF. Implementations SHOULD support such
control with the granularity of a single destination.
Implementations SHOULD also support such control with the
granularity of an autonomous system, where the autonomous
system may be either the autonomous system that originated
the information or the autonomous system that advertised the
information to the local system (adjacent autonomous system).
o The default MUST be to import nothing from BGP/IDRP into
OSPF. Administrators must configure every destination
they wish to import.
A configuration parameter MAY allow an administrator to
configure an ASBR to import all the set of reachable
destinations from BGP/IDRP into the OSPF routing domain.
3. The administrator MUST be able to configure the OSPF cost and
the OSPF metric type of every destination imported into OSPF.
o The OSPF cost MUST default to the LOCAL_PREF value; the
OSPF metric type MUST default to type 2.
4. Information learned via BGP/IDRP from peers within the same
AS MUST not be imported into OSPF.
5. The ASBR MUST never generate a default destination into the
OSPF routing domain unless explicitly configured to do so.
A default destination is a set of all possible destinations.
By convention, it is represented as a prefix of 0 length or a
mask of all zeroes.
A possible criterion for generating default into an IGP is to
allow the administrator to specify a set of (set of reachable
Varadhan [Page 6]
INTERNET DRAFT (Expires September 15, 1993) March 93
destinations, PATH, default cost, default type) tuples. If
the ASBR learns of at least one of the destinations in the
set of reachable destinations, with the corresponding PATH,
then it generates a default destination into the OSPF routing
domain, with the appropriate cost and type. The lowest cost
route will then be injected into the OSPF routing domain.
This is the recommended method for originating default
destinations in the OSPF routing domain.
6. Note that [RFC1247] requires the network number to be used as
the Link State ID. This will produce a conflict if the ASBR
tries to import two destinations, differing only in their
prefix length. An implementation conforming to [RFC1247]
MUST, in this case, drop the more specific route, i.e. the
route corresponding to the longer prefix in the reachability
information. The OSPF WG is working on revising [RFC1247].
The revised version will incorporate hooks to handle the
conflict.
3. BGP/IDRP Identifier and OSPF router ID
The BGP/IDRP identifier MUST be the same as the OSPF router id at all
times that the router is up.
Note that [BGP-4] requires that the BGP identifier be an address
assigned to the BGP speaker.
In the case of IDRP, the IDRP protocol does not explicitly carry the
identity of the IDRP speaker. An implicit notion of the identity of
the IDRP speaker can be obtained by examining the source address in
the IP packets carrying the IDRP information. Therefore, all IDRP
speakers participating in the OSPF protocol MUST bind the IDRP
identifier to be the address of the OSPF router id.
This characteristic is required for two reasons.
i Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
belong to the same autonomous system.
Varadhan [Page 7]
INTERNET DRAFT (Expires September 15, 1993) March 93
+-----+
| RT3 |
+-----+
|
Autonomous System running OSPF
/ \
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
Both RT1 and RT2 can reach an external destination X and
import this information into the OSPF routing domain. RT3 is
advertising this information about destination X to other
external BGP/IDRP speakers. RT3 must use the OSPF router ID
to determine whether it is using RT1 or RT2 to forward packets
to destination X and hence build the correct PATH to advertise
to other external speakers.
More precisely, RT3 MUST determine which ASBR it is using to
reach destination X by matching the OSPF router ID for its
route to destination X with the BGP identifier of one of the
ASBRs, or the IP source address of the IDRP protocol packet
from one of the ASBRs; it MAY then generate the corresponding
network layer reachability information for further
advertisement to external BGP/IDRP peers.
ii It will be convenient for the network administrator looking at
an ASBR to correlate different BGP/IDRP and OSPF information
based on the identifier.
4. Setting OSPF tags, ORIGIN and PATH attributes
The OSPF external route tag is a ``32-bit field attached to each
external route . . . It may be used to communicate information
between AS boundary routers; the precise nature of such information
is outside the scope of [the] specification.''[RFC1247]
OSPF imports information from various routing protocols at all its
ASBRs. In some instances, it is possible to use protocols other than
EGP or BGP across autonomous systems. It is important, in BGP/IDRP,
to differentiate between reachable destinations that are external to
the OSPF routing domain but must be considered internal to the AS, as
opposed to reachable destinations that are external to the AS.
Varadhan [Page 8]
INTERNET DRAFT (Expires September 15, 1993) March 93
Reachable destinations that are internal to the AS and that may or
may not be external to the OSPF routing domain will not come to the
various BGP/IDRP speakers from other BGP/IDRP speakers within the
same autonomous system via BGP/IDRP. Therefore, ASBRs running
BGP/IDRP must have knowledge of this class of reachable destinations
so that they can advertise these destinations to the various external
AS without waiting for BGP/IDRP updates from other BGP/IDRP speakers
within the same autonomous system about these destinations.
Additionally, in the specific instance of an AS intermixing routers
running EGP and BGP/IDRP as external gateway routing protocols, using
OSPF as an IGP, then within the autonomous system, it may not be
necessary to run BGP/IDRP with every ASBR running EGP and not running
BGP/IDRP, if this information can be carried in the OSPF tag field.
We use the external route tag field in OSPF to intelligently set the
ORIGIN and PATH attributes in BGP/IDRP. These attributes are well-
known, mandatory attributes in the respective protocols. The exact
mechanism for setting the tags is defined below.
The tag is broken up into sub-fields shown below. The various sub-
fields specify the characteristics of the set of reachable
destinations imported into the OSPF routing domain.
The high bit of the OSPF tag is known as the ``Automatic'' bit. When
this bit is set to 1, the following sub-fields apply:
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a|c|p l| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, indicating that the
Completeness and PathLength bits have been generated
automatically by a router. The meaning of this characteristic
and its setting are defined below.
c is 1 bit of Completeness information. The meaning of this
characteristic and its settings are defined below.
pl are 2 bits of PathLength information. The meaning of this
characteristic and its setting are defined below.
ArbitraryTag
is 12 bits of tag information, which defaults to 0 but can be
configured to anything else.
Varadhan [Page 9]
INTERNET DRAFT (Expires September 15, 1993) March 93
Note: for IDRP the value must be zero if the standard fixed
format header to the AS number is used. Otherwise, the value
indicates a index into a table of fixed headers for the IDRP
Routing Domain Identifier.
AutonomousSystem (or ``AS'')
is 16 bits, indicating the AS number corresponding to the set
of reachable destinations, 0 if the set of reachable
destinations is to be considered as part of the local AS.
local_AS
The term `local_AS' refers to the AS number of the local
OSPF routing domain.
next_hop_AS
`next_hop_AS' refers to the AS number of an external BGP
peer.
When the Automatic bit is set to 0, the following sub-fields apply:
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, set to 0.
LocalInfo
is 31 bits of an arbitrary value, manually configured by the
network administrator.
The format of the tag for various values of the characteristics
bits is defined below.
4.1. Semantics of the characteristics bits
The Completeness and PathLength characteristics bits define the
characteristic of the set of reachable destinations imported into
OSPF from other ASBRs in the autonomous system. This setting is
then used to set the ORIGIN and PATH attributes when re-exporting
these reachable destinations to an external BGP/IDRP speaker.
o The Automatic characteristic bit is set when the Completeness
and PathLength characteristics bits are automatically set by
a border router.
Varadhan [Page 10]
INTERNET DRAFT (Expires September 15, 1993) March 93
For backward compatibility, the Automatic bit must default to
0 and the network administrator must have a mechanism to
enable automatic tag generation. Nothing must be inferred
about the characteristics of the OSPF address/mask pair from
the tag bits, unless the tag has been automatically
generated.
o The Completeness characteristic bit is set when the source of
the incoming route is known precisely, for instance, from an
IGP within the local autonomous system or EGP at one of the
autonomous system's boundaries. It refers to the status of
the path information carried by the routing protocol.
o The PathLength characteristic sub-field is set depending on
the length of the PATH that the protocol could have carried
when importing the reachability information into the OSPF
routing domain. The length bits will indicate whether the
PATH attribute for the length is zero, one, or greater than
one.
Reachable destinations imported from an IGP will usually have
a PATH of length of 0, reachable destinations imported from
an EGP will have an PATH of length 1, BGP/IDRP and routing
protocols that support complete path information, either as
BGP AS_PATHs or IDRP routing domain paths(RD_PATHs), will
indicate a path greater than 1.
The OSPF tag is not wide enough to carry path information
about reachable destinations that have an associated
PathLength greater than one. Path information about these
destinations will have to be carried via BGP/IDRP to other
ASBRs with the same autonomous system. Such destinations
must not be exported from OSPF into BGP/IDRP.
In the following sections, the code YES will have value 1, and the |
code NO will have value 0.
4.2. Configuration parameters for setting the OSPF tag
o There MUST be a mechanism to enable automatic generation of
the tag characteristic bits.
o Configuration of an ASBR running OSPF MUST include the
capability to associate a tag value, for the ArbitraryTag, or
LocalInfo sub-field of the OSPF tag, with each instance of a
Varadhan [Page 11]
INTERNET DRAFT (Expires September 15, 1993) March 93
routing protocol.
o Configuration of an ASBR running OSPF MUST include the
capability to associate an AS number with each instance of a
routing protocol.
Associating an AS number with an instance of an IGP is
equivalent to flagging those set of reachable destinations
imported from the IGP to be external destinations outside the
local autonomous system.
Specifically, when the IGP is RIP[RFC1058], it SHOULD be
possible to associate a tag and/or an AS number with every
interface running RIP on the ASBR.
4.3. Manually configured tags
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This tag setting corresponds to the administrator manually
setting the tag bits. Nothing MUST inferred about the
characteristics of the set of reachable destinations
corresponding to this tag setting.
For backward compatibility with existing implementations of
OSPF currently deployed in the field, this MUST be the default
setting for importing destinations into the OSPF routing
domain. There MUST be a mechanism to enable automatic tag
generation for imported destinations.
The OSPF tag to BGP/IDRP attribute mappings for these reachable
destinations MUST be
Automatic=NO, LocalInfo=Arbitrary_Value => |
ORIGIN=<EGP>, PATH=<local_AS> |
Varadhan [Page 12]
INTERNET DRAFT (Expires September 15, 1993) March 93
4.4. Automatically generated tags
4.4.1. Destinations with incomplete path information, PathLength =
0
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with incomplete path information and cannot or may
not carry the neighbour AS or AS path (and hence the IDRP
RD_PATH) as part of the routing information.
The OSPF tag to BGP/IDRP attribute mappings for these
destinations MUST be
Automatic=YES, Completeness=NO, PathLength=00, AS=0 =>
ORIGIN=<EGP>, PATH=<local_AS>
4.4.2. Destinations with incomplete path information, PathLength =
1
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with incomplete path information. The neighbour AS
(and therefore IDRP RD) is carried in the routing information.
The OSPF tag to BGP/IDRP attribute mappings for these
destinations MUST be
Automatic=YES, Completeness=NO, PathLength=01, AS=<next_hop_AS>
=> ORIGIN=<EGP>, PATH=<local_AS, next_hop_AS>
This setting SHOULD be used for importing reachable
destinations from EGP into the OSPF routing domain. This
setting MAY also be used when importing reachable destinations
from BGP/IDRP whose ORIGIN=<EGP> and PATH=<next_hop_AS>; if the
BGP/IDRP learned route has no other transitive attributes, then
its propagation via BGP/IDRP to ASBRs internal to the
autonomous system MAY be suppressed.
Varadhan [Page 13]
INTERNET DRAFT (Expires September 15, 1993) March 93
4.4.3. Destinations with incomplete path information, PathLength
>= 1
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with truncated path information.
The OSPF tag to BGP/IDRP attribute mappings for these
destinations MUST be
Automatic=YES, Completeness=NO, PathLength=10, AS=don't care
These are imported by a border router, which is running
BGP/IDRP to a stub domain, and not running BGP/IDRP to other
ASBRs in the same autonomous system. This causes a truncation
of the PATH. These destinations MUST not be re-exported into
BGP/IDRP at another ASBR.
4.4.4. Destinations with complete path information, PathLength = 0
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with either complete path information or are known to
be complete through means other than that carried by the
routing protocol.
The OSPF tag to BGP/IDRP attribute mappings for these
destinations MUST be
Automatic=YES, Completeness=YES, PathLength=00, AS=00
=> ORIGIN=<EGP>, PATH=<local_AS>
This SHOULD be used for importing reachable destinations into
OSPF from an IGP.
Varadhan [Page 14]
INTERNET DRAFT (Expires September 15, 1993) March 93
4.4.5. Destinations with complete path information, PathLength = 1
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with either complete path information, or are known
to be complete through means other than that carried by the
routing protocol. The routing protocol also has additional
information about the next hop AS or RD, the destination was
learned from.
The OSPF tag to BGP/IDRP attribute mappings for these
destination MUST be
Automatic=YES, Completeness=YES, PathLength=01, AS=next_hop_AS
=> ORIGIN=<IGP>, PATH=<local_AS, next_hop_AS>
This setting SHOULD be used when the administrator explicitly
associates an AS number with an instance of an IGP. This
setting MAY also be used when importing reachable destinations
from BGP/IDRP whose ORIGIN=<IGP> and PATH=<next_hop_AS>; if the
BGP/IDRP learned route has no other transitive attributes, then
its propagation via BGP/IDRP to other ASBRs internal to the
autonomous system MAY be suppressed.
Varadhan [Page 15]
INTERNET DRAFT (Expires September 15, 1993) March 93
4.4.6. Destinations with complete path information, PathLength >=1
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are reachable destinations imported from routing
protocols with complete path information and carry the AS path
information as part of the routing information.
The OSPF tag MUST be set to
Automatic=YES, Completeness=YES, PathLength=10, AS=don't care
These destinations MUST not be exported into BGP/IDRP because
these destinations are already imported from BGP/IDRP into the
OSPF RD. Hence, it is assumed that the BGP/IDRP speaker will
convey this information to other BGP/IDRP speakers within the
same autonomous system via BGP/IDRP. As ASBR learning of such
a destination MUST wait for the BGP update from its internal
neighbours before advertising it to external BGP/IDRP peers.
Note that an implementation MAY import reachable destinations
from BGP/IDRP with a path length of 1 and no other transitive
attributes directly into OSPF and not send these routes via
BGP/IDRP to ASBRs within the same autonomous system. In this
situation, it MUST use tag settings corresponding to 4.4.2, or
4.4.5.
4.5. Miscellaneous tag settings
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|x|1|1| Reserved for future use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of PathLength=11 is reserved during automatic tag
generation. Routers must not generate such a tag when importing
reachable destinations into the OSPF routing domain. ASBRs must
ignore tags which indicate a PathLength=11.
Varadhan [Page 16]
INTERNET DRAFT (Expires September 15, 1993) March 93
4.6. Summary of the tag sub-field setting
The following table summarizes the various combinations of
automatic tag settings for the Completeness and PathLength sub-
field of the OSPF tag and the default behaviour permitted for each
setting.
Completeness := 0 | 1
PathLength := 00 | 01 | 10 | 1
ORIGIN := <IGP> | <EGP>
PATH := valid AS path settings as defined in BGP [BGP-4],
and IDRP for IP[IDRP].
PathLength ==> 00 01 10 11
Completeness
|| +--------------------------------------------------------------------
vv |
= NO | <EGP> <EGP> never export reserved
| <local_AS> <local_AS,next_hop_AS>
|
= YES | <IGP> <IGP> out of band reserved
| <local_AS> <local_AS,next_hop_AS>
|
The "out of band" in the table above implies that OSPF will not be
able to carry everything that BGP needs in its routing
information. Therefore, some other means must be found to carry
this information. In BGP, this is done by running BGP to other
ASBRs within the same autonomous system.
5. Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute
Forwarding addresses are used to avoid extra hops between multiple
routers that share a common network and that speak different routing
protocols with each other on the common network.
Both BGP/IDRP and OSPF have equivalents of forwarding addresses. In
BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory
attribute. OSPF has a Forwarding address field. We will discuss how
these are to be filled in various situations.
Varadhan [Page 17]
INTERNET DRAFT (Expires September 15, 1993) March 93
Consider the 4 router situation below:
RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
RT1 and RT3 are talking BGP/IDRP with each other. RT3 and RT4 are
talking OSPF with each other.
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
| | common network
---+-----------------------+--------------------------
<BGP/IDRP> | |
+-----+ <OSPF> +-----+
| RT3 | | RT4 |
+-----+ +-----+
- Importing a reachable destination into OSPF:
When importing a destination from BGP/IDRP into OSPF, RT3 MUST
always fill the OSPF Forwarding Address with the BGP/IDRP
NEXT_HOP attribute for the destination.
- Exporting a reachable destination into BGP:
When exporting set of reachable destinations internal to the
OSPF routing domain from OSPF to BGP/IDRP, if all the
destinations in the set of reachable destinations are through
RT4, then RT3 MAY fill the NEXT_HOP attribute for the set of
reachable destinations with the address of RT4. This is to
avoid requiring packets to take an extra hop through RT3 when
traversing the AS boundary. This is similar to the concept of
indirect neighbour support in EGP[RFC888, RFC827].
6. Changes from the BGP 3 - OSPF interactions document
o The use of the term "route" has attained a more complicated
structure in BGP 4. This document follows the constraint in
the manner shown below:
- The term "set of reachable destinations" is called a NLRI
in [BGP-4].
- The term "route" in the BGP context refers to a set of
reachable destinations, and the associated attributes for
the set.
- The term "route" in the OSPF context refers to the set of
reachable destinations, and the cost and the type to
Varadhan [Page 18]
INTERNET DRAFT (Expires September 15, 1993) March 93
reach destinations. This is to keep the definitions
consistent in the document.
o The notion of exchanging reachability information between BGP
4 and OSPF has been updated to handle variable length net mask
information.
o The previous term INTER_AS_METRIC in BGP 3 has now been
changed to MULTI_EXIT_DISC.
o The default metric to be used for importing BGP information
into the OSPF RD is now the LOCAL_PREF attribute, instead of a
constant value.
o BGP 4 requires that the BGP identifier be an address assigned
to the BGP speaker. This is dealt with in section 3.
o Section 5 on setting NEXT_HOP attributes and Forwarding
Address field has been updated to account for variable length
net information.
o Section 2 which requires an ASBR to match the OSPF tag
corresponding to a route to the BGP Identifier, can cause
potential loops if the AS has equal cost multipath routing
amongst the ASBRs. This scenario is outlined in the Appendix
below.
o This section, 6, has been added.
7. Security Considerations
Security considerations are not discussed in this memo.
8. Acknowledgements
I would like to thank Jeff Honig (Cornell University), John Moy
(Proteon, Inc.), Tony Li (cisco Systems), Rob Coltun (Consultant),
Dennis Ferguson (ANS, Inc.), and Phil Almquist (Consultant) for their
help and suggestions in writing this document, without which I could
not have written this document. I would also like to thank them for
giving me the opportunity to write this document, and putting up with
my muddlements through various phases of this document.
We would also like to thank the countless number of people from the
OSPF and BGP working groups who have offered numerous suggestions and
comments on the different stages of this document.
Thanks also to Bob Braden (ISI), whose suggestions on the earlier
Varadhan [Page 19]
INTERNET DRAFT (Expires September 15, 1993) March 93
BGP-OSPF document, [RFC1403] were useful even for this one, and have
been carried through.
9. Bibliography
[RFC827] Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October
1982.
[RFC888] Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior
Gateway Protocol'', January 1984.
[RFC1058] Hedrick, Charles, L., ``Routing Information Protocol'', June
1988.
[RFC1122] Braden, R.T., ed., ``Requirements for Internet hosts -
communication layers'', October 1989.
[RFC1123] Braden, R.T., ed., ``Requirements for Internet hosts -
application and support'', October 1989.
[RFC1247] Moy, John, ``The OSPF Specification Version 2'', January
1991.
[RFC1338] Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan,
``Supernetting: an Address Assignment and Aggregation Strategy'',
June 1992.
[RFC1403] Varadhan, Kannan; ``BGP OSPF Interaction''; January 1993.
[ROUTE-LEAKING] Almquist, Philip, ``Ruminations on Route Leaking'', in
preparation.
[NEXT-HOP] Almquist, Philip, ``Ruminations on the Next Hop'', in
preparation.
[BGP-4] Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway
Protocol 4 (BGP-4)'', in preparation.
[IDRP] Hares, Susan; ``IDRP for IP'', in preparation
Varadhan [Page 20]
INTERNET DRAFT (Expires September 15, 1993) March 93
10. Appendix
X
/ \
/ \ +----+
/ \ / \
/ +--------+ |
/ | C1 C2 | |
| |Domain C| |
B | C3 | |
| +--------+ |
\ / |
\ / /
\ / /
\ / /
+--------+ /
| A1 A2 | /
|Domain A| /
| A3 | /
+--------+ /
\ /
\ /
\ /
S
Given the domains, X, A, B, C and C, let domains A and C be running
OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2
and C1, C2 respectively. The picture above shows the internal
structure of domains A and C only.
During steady state, the following are the route advertisements:
o Domain B advertises to A path <B,X>
o ASBR A3 in domain A advertises path <A,B,X> to domain C, at
ASBR C2.
o Domain C has two equal cost paths to X: one direct <C,X>, and
another through A <C,A,B,X>
o BR C3 in domain C advertises to A2 path <C,X>
o Domain A has two equal cost paths to X: <A,C,X> and <A,B,X>
Both C1 and C2 inject a route to X within the domain C, and
likewise A1 and A2 inject a route to X within the domain A. Since
Varadhan [Page 21]
INTERNET DRAFT (Expires September 15, 1993) March 93
A3 and C3 see equal cost routes to X through A1, A2 and C1, C2
respectively, a stable loop through ASBRs <A3, A2, C3, C2, A3>
exists, which is used by these routers for load splitting with
equal cost multi-path routing.
11. Author's Address:
Kannan Varadhan
Internet Engineer, OARnet,
1224, Kinnear Road,
Columbus, OH 43212-1136.
email: kannan@oar.net
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
e-mail: yakov@watson.ibm.com
Varadhan [Page 22]